<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Library projects</title>
  <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body text="#000000" bgcolor="#FFFFFF">

<table width="100%">
<tr><td style="background:#0080C0"><b><span style="color:white">Library projects</span></b></td></tr>
</table>
<font size="-1">Last modified: January 20, 2006</font> 
<p>
<h3>The Problem</h3>
<p>
Eclipse users often have a large number of projects in their workspace.  Typically
a small set of these projects are under active development, and the remainder
are just present for the purpose of browsing or because they are required to build,
launch, or test the projects being developed.  However, the 
workspace still performs the work of tracking changes in these projects, and 
performing incremental builds.  Similarly, language tools such as JDT expend
effort to maintain their model of the state of those projects, and to rebuild
search indices as the projects change.  Much of this overhead could be
reduced or eliminated if there was a way to configure a project as a library project
that is not under active development in that particular workspace.
</p>
<h3>Proposed Solution</h3>
<p>
Support could be added in the resource API to put a project in library mode.
A project in library mode will not respond to incremental build requests, either
from auto-build, or manual incremental builds.  When entering library mode
at the GUI level, the user will be encouraged to perform one final build on the
project to ensure its built state is up to date.  Users will be discouraged from
modifying source artifacts in projects in library mode via the resource modification validator.
</p>
<p>
When a project is in library mode, language tools are encouraged to no longer 
track the state of source artifacts in the project. Built state can still be referenced 
for purposes of compiling non-library projects in the workspace.  For example, 
JDT would no longer maintain its Java model based on the project source, but 
rather treat the project's output directories as library folders.  Changes to built artifacts
such as class files, JARs, and DLLs would still be reacted to. Changes to source
artifacts would be ignored (with appropriate warning at the time of modification).
</p>
<p>
When a project is removed from library mode, the user is encouraged to perform
a full workspace build (or if autobuild is on, it will just happen without user
interaction).  Library projects will receive a full build, and all downstream projects
will be built incrementally.
</p>
<h3>Open Problems</h3>
<p>
<ul>
<li>Is there a significant benefit to designating a project as a library project?  Are
users well served by the current scoped build mechanism as a way to reduce
the cost of building a large workspace? We have had no feedback on the plan item bug.</li>
<li>Will it be confusing that modifications to source in a library project have no effect?</li>
<li>Should there still be a way to force a build of a library project? Does it make
sense for global workspace builds to ignore library projects, but still build them
when a single project (or group of projects) is selected for compilation?</li>
</ul>
<h3>References</h3>
<p>
Plan item <a href = "https://bugs.eclipse.org/bugs/show_bug.cgi?id=80162">bug 80162</a>.
</p>
</body>
</html>